Certain network storage servers have the ability to create a read-only, persistent, point-in-time image (PPI) (sometimes called a “snapshot”) of a data set, such as a volume or logical unit. This capability allows the exact state of the data set to be restored from the PPI in the event of a catastrophic failure of the storage system or data corruption. The ability to restore data from a PPI provides system administrators with a simple mechanism to revert the state of their data to a known previous point in time as captured by the PPI.
A storage server typically maintains various metadata structures in persistent storage (e.g., on disk) to indicate the current allocation status (i.e., allocated or free) of all blocks of storage in the system. These metadata structures are used to facilitate write allocation decisions. A “block” in this context is the smallest unit of data that the storage system can independently manage, which in at least one known network storage system is a 4 Kbyte chunk of data. These metadata structures can be in the form of one or more bitmaps, where each entry in such a bitmap corresponds to, and represents the allocation status of, a different block of storage. An “entry” in a bitmap can be a single bit or a group of bits in this context.
However, the need to repeatedly read and update these metadata structures on disk can create significant overhead and operational inefficiencies in a storage server. In at least one known storage server, a separate bitmap is maintained for the active file system and for each PPI that the storage system maintains. To facilitate explanation, the bitmap for the active file system is called the “active map” herein, while the bitmap of a PPI (snapshot) is called a “PPI map” herein. The active file system and PPIs may share a common pool of storage. In that case, each block of storage managed by the storage server is represented by a corresponding bit in the active map and in each PPI map. The collective state of each block in all PPIs is represented in yet another bitmap, called a “summary map”, which along with the active map is used to make write allocation decisions. The status of any particular block indicated in the summary map may be a simple logical OR of the corresponding bits in each PPI map. Consequently, when determining the allocation status of blocks, such as when preparing to execute a write operation, the storage server determines the status of any particular block from the indicated status of that block in the summary map and the active map.
In one known system, the summary map is updated immediately after a PPI is generated. For example, after a PPI is generated a scan of the on-disk PPI map for that PPI is performed to update block allocation status in the summary map. However, this scan is time consuming and resource intensive, at least partly because it involves numerous disk reads, which involve significant latency.
Further, a bit array is sometimes used to keep track of the map scan progress by assigning one bit for each bitmap block. The memory consumed by this bit array is overhead, which can be significant in size if the system maintains a large number of volumes and supports thin provisioning. This overhead can reduce the overall operational efficiency of the storage system. In addition, the map scan process is performed each time a block is to be freed resulting in additional disk reads during block frees. The performance penalty of PPI creation, therefore, can be substantial.